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CLIENT OBJECT API AND GATEWAY TO stateless, meaning that a Web server retains no information 

ENABLE OLTP VIA THE INTERNET about a particular client with which to influence any future 

interactions with that client. 

The present invention provides an apparatus and method Gaining access to the Web is often a primary motivation 
in a data processing system for connecting a client program 5 behind efforts to build intranets and to get private WANs 

with a server program across a network. connected to the Internet. Once connected, the computer 

user has a high-speed connection to the world, but ironically 

BACKGROUND OF THE INVENTION ^igh speed connection most often cannot be used to 

Over the years of computerized data processing, commer- connect a geographically remote user to a company server 

cial enterprises have built large legacy databases on central for U-ansaction processing. 

computers. Desktop PCs connected via LANs, rather than There are two main reasons why the Internet has not been 

dumb terminals with direct connections, have become the to support traditional on-line transaction processing, 

means of accessing these databases. Furthermore, in on-line py-gt, the TTM employed cannot communicate using the 

transaction processing systems, PCs have taken on a role in protocols of the Internet. Second, client applications are 

the actual processing of a transaction, creating a distributed written dependent on operating characteristics of the LAN 

computing environment (DCE). Transaction processing not shared by the Internet. 

monitor (TPM) programs running on central computers have ^^^^^^ differences between a LAN and the Internet make 

also been expanded to operate m the DCE. TPMs which suitable for LANs difficult to use with the Internet, 

formerly communicated keyboard input and display output ^^^^ j^^^^^^j ^^^^ immense geography, 

data streams, have been expanded to communicate service potentially long distances can result in slow response 

requests and rephes. Other "server" programs have been j^^^^^^^ instantaneously constructs a virtual cir- 

created specificaUy for the DCE which commumcate only ^^.^ ^^^^ communication with varying rehability outside 

service requests and rephes. The standard of DCE comput- ^^^^^^ ^^^^ ^^-^^ ^ANs are generally more 

ing has become the client-server model. reliable. The pubhc nature of the Internet introduces privacy 

In client-server computing there is interaction between security concerns not as relevant to LANs. Lastly, some 

two computers usually connected by a local area network, or internet protocols are stateless and unusable for "stateful" 

LAN. The first computer, the client, requests a data process- transaction processing. 

ing operation be perfonned on the sec«nd comP:uter^ transaction processing across the 
server, as a step m achieving its ^^^'^^^^^^^^^^ 30 internet has been successfuUy accomphshed. One imple- 

example, because legacy databases are often centrahzed on "translation server'' (see Perrochon, "Trans- 

amediumorlargescalecomputer.thesecomp^^^^^^^^ Sn Servers: Gateways Between Stateless and Stateful 

as database servers, adding, changing or deletmg database ^^^^^^.^^ Systems"). Translation servers are, however, 

mformation m response to a request from a client PC ^^^^^^^ the "TPM to dumb terminal" model of on-hne 

Seiver programs commonly make their semces available ^j.3nsactioo processing. The translation server essentiaUy 

to the chent program through a remote procedure call (RPC) translates the dumb-terminal display format information into 

mechanism . The chent program typicaUy makes many pro- ^^^^^^ ^^^^^^ ^ browser. The translation 

cedure calls during its execuuon. These procedures execute ^^^^^ translates user input from the browser into 

on the same computer as the client program. Each procedure ^^^^^ ^ for the TPM. 

generally performs a small, discrete data processing opera- ^ ' ^ ^ . ^ 

tion When a remote procedure call is made, a request to Another miple mentation of transaction processmg across 

perform the procedure is transmitted across the LAN to the the Internet is an RPC gateway, ms mipleinentalion is 

server computer, where the procedure is executed and some directed at the chent-server model. DCE Enema Lightweigh 

result is returned to the cUem. CIient(TM) from Transarc Corporation is a commercial 

Users too geographically distant to be directly attached to ,5 ^^^^V^^ ^^is methodology. In S^j^^^/^^^ 

v^jsQio luu ^i^v/g ^ . / , I „„^r acts as an mtermediary, acceptmg RPC requests from the 

the LAN tvoicallv need to make a dial-up connection over . xxx j, ^ . ^ „ / 

me Lrti^i iypit.duy uc,pu h ^^^^ Internet connection. The gateway processor 

a phone hue and attach to the LAN or the ^J^^^^^^^ fo^,,ds the request to the server appUcation via a 

order to mn progmmswntten for the DCE. Because of the ^^^-^^t-^^ ^j^J^.j i^^^i^ format natively 

limited bandwidth of switched telephone hues, this usually ^^^^ to the server ajphcation. Responses from the 

means a great sacrifice in speed. In many applications the ^^^^^ ^^e cUent similarly tLel back through the gateway 

speed problem is severe enough to preclude dial-up usage je^^^^^ ^^^^.^^^^ ^^^^^^^ ^^^^^^^ processors can be 

altogether. deployed to improve reliability. 

At the same time that the number of LANs and chent- ^-^ 

server DCEs was rapidly expanding, so was the Internet. T^e RPC gateway model has several disadvantages. For 
LANs were being interconnected into private wide area 55 *^^^"^Pl«' ^^^^ ^ ^P^^^^^ 8^*^^"^ processor may be 

networks, or WANs. These private WANs were in turn being prohibitive if required. In addition, the potentially long 

connected into the global WAN known as the Internet. Some response time of the Internet compared to a LAN can slow 

private WANs arc constructed using the technology base of the appUcaUon unacceptably. Apphcations which issue naul- 

ihe Internet, foraning what are caUed intranets. tiple RPC^ per transaction are especiaUy stisceptible^ 

T . £ , . . - u ♦ • Accordingly, wh^e RPC gateways allow TPMs to be used 

The fastest grow ng portion of the Internet is what is 60 "^^Ji^^e^J. f ^ . -tuxm^ k, «„ 

I \u wvu u/^K r«www« nr "WpH" for the Internet, many of the advantages TPMs brmg to 

^ Y u^^ !u ^ ' Z \ w^h networks cannot be achieved using the RPC gateway model, 

short). The Web is budt on the client-server model. Web "''^ ^ . 

browsers are the client programs. These browsers take a Consequently, being able to connect a client program with 

document formatted in HTML, generate its visual display, a server program across the Internet or a similar network in 
and perform any associated processing. Web servers, deliver 65 a way that allows for the advantages of TPMs to be utilized 

an HTML document, or "Web page," to a Web browser when on the Internet would be a significant advance over existing 

requested. With all existing Web browsers, the interaction is systems. 
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Thus several objects of the present invention include: FIG. 1 presents a block diagram of the mvention as used 

in a data processing system. 

allowing legacy on-line transaction processing systems to ^ presents an illustration of the operating environ- 

exploit Internet-like networks for client-server comput- ^^^^ embodiment. 

. , u ^ FIGS. 3(AHE) present illustrations of gateway executor 

minimizing the network trafGc required to complete the protocol elements, 

server processing for a transaction. ^ ^^^^^ ^ ^^^^^ ^.^^^^^ ^ ^^^^^^y 

providing sophisticated use of network connections by ^ present a flowchart of message handler process- 
servicing multiple clients from an individual server 

, FIG. 6 presents a flowchart of reply monitor processing, 

maintaining essential data about the chent apphcation ^ ^^^^ ^ ^ ^^^^^ communica- 

state m a controlled environment on the server rather K ^ 
than on the client processor or in the protocol. 

increasing the reliabiUty and recover ability of a transac- DETAILED DESCRIPTION OF THE 

tion processing system operating over an unreliable INVENTION 

network. present invention provides an apparatus and method 

providing a general purpose, high-level interface between ^ ^ ^j^^^ processing system for connecting a cUent program 

client applications and server-based services which ^^j, ^ ^g^^j. program across a network. In the following 

hides the complexity of using the service from the 20 description, numerous details are set forth for purpose of 

client application. explanation. However, one of ordinary skill in the art would 

improving the scalability of server support for clients realize that the invention may be practiced without the use 

connected via Internet-like networks. of these specific details, 

enabling deployment of client application programs Id other instances, well-known structures, devices and 

which utilize commonplace Web browsers for their 25 methods are shown in block diagram form or summarily 

user interface. described in order not to obscure the description of the 

The present invention provides these advantages of bring- invention with unnecessary detail. This is notably true 

ing TPMs to the Internet, and thus provides significant regarding means employed in modem-day computer sys- 

advantages over existing systems. tems for inter-process communication, inter-component 

transfer of data and processing control, inter-component 

SUMMARY OF THE INVENTION connection, and program interfacing to a physical network 

through layered service routines often part of the operating 

The present invention provides an apparatus and method system, 

in a data processing system for connecting a client program FIG. 1 sets forth one embodiment of the invention as used 

with a server program across a network. One embodiment of in a data processing system 101. The system includes one or 

the invention includes a gateway executor program running more client processors 110 and a server processor 120. Each 

on the server computer which is able to conduct service client processor 110 is able to communicate bidirectionally 

request transactions with a target service program. An appli- with the server processor 120 over a wide-area data com- 

cation programming interface running on the client com- munications network 130 (WAN). 

puter abstracts the complex technical particulars of conduct- in certain instances, especially where the WAN employed 

ing service request transactions to a level focusing on the is the Internet, the network path from the client processor 

desired result, and presents available service request types as 110(2) to the server processor 120 may include one or more 

behaviors to a client application program. The application firewalls 132 which filter out unauthorized or unnecessary 

programming interface talks to the gateway executor pro- network trafGc. If this is the case, and the firewalls 132 

gram through a communications manager on the client, obstruct the passage of network messages used by an 

interfacing to the network. Messages passed among the embodiment to practice the invention, then firewall nego- 

gateway executor, the applications programming interface, tiators 134 may be installed to allow such network messages 

and the client communications manager utilize a gateway to traverse the entire network path from the client processor 

executor protocol to achieve coordination and cooperation. 110(2) to the server processor 120. Firewalls and firewall 

Data regarding the state of interactions between the client negotiation are well known in the art. 

and the server are maintained in a controlled fashion on the g^^jj (.jj^^ processor 110 hosts a client application 112, 

server to improve recovery and reliability. The embodiment application programming interface 114 (API), a client 

permits legacy on-line transaction processing systems to communication manager 116 (CCM), a connection 113 

operate effectively over relatively unreliable wide area net- between the client application 112 and the API 114, a 

works such as the Internet. connection 115 between the API 114 and the CCM 116, and 

These and other objects and advantages of the invention an attachment 117 to the network 130. 
will become apparent to one of ordinary skill in the art upon The server processor 120 hosts a gateway executor pro- 
consideration of the following DetaUed Description and the gram 122, a target service program 124, a connection 123 
Drawings, 60 between them, and an attachment 125 to the network 130. 

The client application program 112 executing on the client 

BRIEF DESCRIPTION OF THE DRAWINGS processor 110 is written for a distributed computing envi- 
ronment (DCE). As such, it relies to some extent on services 

The novel features of the invention are set forth in the provided by the target service program 124 executing on the 

appended claims. However, for purpose of explanation, 65 server processor 120 to perfonn its function. To connect 

several embodiments of the invention are described by with the target service program 124, the client application 

reference to the following figures. 112 communicates with the application programming inter- 
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face 114. The client application 112 invokes behaviors 
presented to it by the API 114 and receives certain resulting 
responses via the API 114. 

The API 114 communicates with the client communica- 
tion manager 116 (CCM) to send and receive messages 
across the network 130 to the gateway executor 122. In some 
embodiments the connection 115 between the API 114 and 
the CCM 116 may be an active one. including processes 
guaranteeing the ACID properties of a transaction conducted 
using the invention. The ACID properties are atomicity, 
consistency, isolation, and durability, and are well known in 
the art. The CCM 116 is attached to the network. 

The gateway executor 122 executes on the server proces- 
sor 120 and is attached to the network 130 to receive and 
process messages directed to it by one or more CCMs 116. 
In response to a received message, the gateway executor 122 
can direct messages to a respective CCM 116. In one 
embodiment of the invention, it is the client processors 110 
that originate communication with the server processors 
120, and not vice versa. Any message directed from a 
gateway executor 122 to a CCM 116 is in response to some 
earlier message directed from the CCM 116. 

Based on the content of messages directed to the gateway 
executor 122 by the CCMs 116. the gateway executor 122 
communicates with the target service program 124 on behalf 
of the client application 112 to request the performance of 
services and to receive replies thereto. The gateway executor 
122 may take a single request originating from the client 
application 112 and from it generate multiple requests to the 
target service program 124. Because each request to the 
target service program 124 is actually a request-reply 
combination, and because the multiplicity of requests to the 
target service program 124 are generated on the server 
processor 120 rather than on the client processor 110, 
network traffic may be greatly reduced which is an advan- 
tage of the present invention. 

In order to service the requests from multiple client 
processors 110, the gateway executor 122 also functions to 
maintain the operating context for each client with an active 
connection, a pending request, or a pending reply. The 
maintenance of the client contexts, discussed in more detail 
below in reference to FIG. 4, provides two further advan- 
tages of the invention. It reduces the coding complexity 
required of the client application, and it provides potential 
for improved recoverability in the event of a failure occur- 
ring mid-transadion. 

Thus an API 114, a CCM 116, a gateway executor 122, 
and the connections between them including a WAN 130 
form a bidirectional active channel between a client appli- 
cation 112 and a target service program 124. The API 114, 
CCM 116, and gateway executor 122 facilitate their end-to- 
end communication using an application level protocol 
referred to as the gateway executor protocol, as will be 
discussed in connection with FIGS. 3(A)-{E). The gateway 
executor protocol inheres in the formatted data structures, 
and the data values having ascribed meanings placed within 
those structures, necessarily exchanged between and among 
the API 114, CCM 116. and the gateway executor 122. 

EMBODIMENT OVERVIEW 

RG. 2 illustrates the operating environment 201 for one 
embodiment of the present invention, planned to be deliv- 
ered in a future commercial ofifering named JOLT(TM) from 
BEA Systems, Inc. 

The server processor 120 hosts a TCP/IP protocol network 
interface 225, a network attachment 229, a gateway executor 
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122, a target service program 124, an HTTP server 221, and 
a storage medium 222. The storage medium 222 contains a 
Web page 223(1) and an associated applet 224(1). 

The client processor 110 attaches input/output devices 211 
and hosts a TCP/IP protocol network interface 213, a net- 
work attachment 213, a Web browser 212, a copy of the Web 
page 223(2), and a copy of the applet 224(2). The applet 224 
contain a client application 112, an API 114, and a CCM 116. 
The client processor 110 and the server processor 120 are 
connected by the Internet 130. 

The server processor 120 in this example is a computer 
capable of running UNIX(TM), though other operating 
systems may be used. The gateway executor 122 executes on 
the server processor 120. Also, other programs execute on 
the server processor 120, these programs being known in the 
art. The target service program 124 is a commercially 
available transaction processing monitor (TPM), named 
TUXEDOfTM). An HTTP server program 221, widely 
referred to as a "Web server", is also known in the art. 

The Internet WAN 130 in this embodiment is TCP/IP 
based. Practitioners in the art recognize that many other 
WAN embodiments are possible. These would include, for 
example, private intranets, or the use of UDP/IP over the 
Internet or an intranet. 

The client processor 110 is a modem desktop computer 
having an Intemet connection 219, TCP/IP software 213, 
and a Web browser 212 supporting JAVA(TM). 

It is noted that in this embodiment certain components are 
loaded into the client processor 110 as the result of the 
computer user instructing the Web browser 212 via the 
input/output devices 211 to retrieve a particular Web page 
223(1). The Web browser 212 issues the request to the HTTP 
server application 221 and in turn receives the Web page 
223(2) and a JAVA(TM) applet 224(2) associated with the 
35 page. The Web browser 212 generates a display of the Web 
page 223(2) for the client processor user and enables the 
applet 224(2). The applet 224(2) contains client application 
112, API 114, and CCM 116 program code. With or without 
further action by the user, the client application 112 code 
40 begins execution. The invention can be as easily practiced in 
embodiments where any or all of the client application 112, 
API 114, and CCM 116 are firmly resident at the client 
processor 110, i.e., not transferred from the server processor 
120. 

45 It is further noted that the connections between the Web 
browser 212 and the the HTTP server application 221, and 
between the client application 112 and the target service 
program 124, are logically isolated. They use the same 
physical network connections 219, 229 on each of the client 
50 processor 110 and the server processor 120 but different 
TCP/IP ports 251, 252; 261, 262. Moreover, because of the 
HTTP protocol used on the Web portion of the Intemet, 
during operation there will likely be no active connection 
between the Web browser 212 and the HTTP server appli- 
es cation 221 during times when the client application 112 is 
requesting services of the target service program 124. 

It is further noted that an embodiment of the gateway 
executor protocol as used in this detailed description is 
illustrated in FIGS. 3(A) through 3(E). The various elements 
60 so illustrated are discussed at various points throughout the 
detailed description to facilitate an understanding of the 
invention. 

GATEWAY EXECUTOR STRUCTURE AND 
g5 INITIALIZATION 

The gateway executor 122 is also executing on the server 
processor 120. FIG. 4 illustrates the gateway executor in its 



01/23/2004, EAST Version: 1.4.1 



6,i: 

7 

initialized state. The gateway executor 122 comprises a 
context data store 416, a data store manager 417, a reposi- 
tory 432, a reply monitor 440, one or more message handlers 
430, a log file 442, an initialization module 410, and a 
network connection 420. 

The log file 442 contains zero or more log entries 443, The 
repository 432 contains one or more repository entries 433. 
The context data store 416 contains zero or more client 
context entries 417 and zero or more pending request entries 
418. 

The operating environment of the gateway executor also 
includes an attachment to the network 125 and the operating 
TPM 124. 

The network connection 420 uses the TCP/IP protocol and 
comprises a single port 262, a listening socket 422, and one 
or more CCM sockets 423. The port 262 multiplexes the 
communications for all client applications connecting with 
the gateway executor. Such multiplexing is an efficient use 
of computing and network resources and represents a further 
advantage of the invention. 

When the gateway executor 122 is first started, an initial- 
ization module 410, INIT, receives control. It establishes the 
network connection 420 by opening a TCP/IP listening 
socket 422 using a port address specified by a startup 
parameter. 

The INIT module 410 further spawns one or moire mes- 
sage handler 430 processes. The number spawned is deter- 
mined by a start-up parameter. The INIT module 410 further 
spawns a reply monitor process 440. Together, the reply 
monitor 440 and the message handlers 430 perform the bulk 
of the ongoing work of the gateway executor 122 and are 
described now in more detail. 

MESSAGE HANDLERS 

Message handlers 430 handle inboimd and outbound 
network traflSc for the gateway executor 122 and initiate 
service request processing. To perform its functions a mes- 
sage handler 430 accesses network messages via the net- 
work connection 420, a context data store 416 via a data 
store manager 414, the target service program 124 via 
procedure calls, and a repository 432. 

One possible format of a repository entry 433 is described 
in the source code depicted in Table 1. Each repository entry 
433 identifies a service type available from the target service 
program 124 and describes one or more parameters associ- 
ated with it. Parameter descriptions may include a name, 
data type, length, and direction, i.e., whether the parameter 
is used for input or output. 

TABLE 1 

Service Def { 
char qName[ J 
int timcOut; 
char iiame[]; 

int number of parameters; 
char ** paramptr; 
int inBufiypei 
int outBuflVpc; 
char inBufName[]; 
char outBufName[]; 

}; 



FIG. 5 shows a flowchart of the main processing loop for 
one embodiment of a message handler 430 suitable for the 
purposes of the present invention. When started the message 
handler, in step 502, polls the network connection 420 to 
determine if there is a new incoming message for it. It will 
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first process messages from client applications with which it 
already has an established connection. Each such established 
connection has a one-to-one correspondence with a CCM 
socket 423 in the network connection 420. Each message 
^ handler 430 can concurrently support multiple client appfi- 
cations to a maximum number specified in a startup param- 
eter. 

In step 504, if there is no new message from an estab- 
lished cormection, and if the message handler is not akeady 
supporting its maximum number of client applications, then 
the message handler will process a first incoming message 
fi-om a client application not yet associated with any mes- 
j5 sage handler. Such messages arrive on the listening socket 
422 shared by all message handlers 430. 

The first message from a client application not associated 
with any message handler is identified by a null value in the 
CID field of the message header and is processed as follows. 
In step 510, a procedure call is made to the target service 
program 124 to establish a new client context. 

In step 512, a unique client ID (CID) is generated and 
recorded in the context data store 416 along with the target 
service program context and other identifying information. 
The CID takes the form of a serial number and is generated 
by the message handler Each CID generated is unique 
within an execution lifetime of the gateway executor 122. A 

30 client context entry 417 in the context data store 416 
conuins the CID and references to target service program 
internal data structures which are used for the purpose of 
managing transactional states of each concurrent client. One 
possible format for a client context entry 417 is described in 

^5 the source code depicted in Table 2. 

TABLE 2 

struct bcClt { 
int state; 
long cUcntld; 
long flags; 
long clientTimeOut; 
long scssionKcy; 
long blockTmie; 
TMCLrCNT?Cr bcCltCntxt; 
long requestCount; 

request„t rqstInfo[BEMAXCLTREQ]; 

}; 



In step 514, the generated CID is sent back to the cUent 
application in the message header of a reply message. At this 
point, the client application has an estab fished connection. In 
step 516, the message handler returns to network polling. 

New messages arriving across the network from client 
applications with established connections are processed by 
the message handler as follows. 

In step 520, the CID from the control header is used to 
retrieve the client context entry 417 from the context data 
60 store. Information from the client context entry 417 is used 
to process the request. 

The message handler then translates parameter data as 
necessary from client application to server-dependent forms 
65 and formats it into a service request structure, in step 522. 
One possible format for a service request stmcture is 
described in the source code depicted in Table 3. 
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TABLE 3 

struct Scrvice[ 
char qName[J 
int timcOut; 
char nameO; 
int opcode; 

int number of parameters; 

char paramptr; 

int inBufrype; 

int outBufiype; 

char inBufNamc[]; 

char outBufName[]; 

int msgHaadte; 

char corrId[32j 

int jotl Error, 

char crrMsgf J 

} 



In step 524, request information is taken from the service 
request structure, and placed into a target service program- 
specific request bufPer format. The message handler then 
sends the request bufifer to the target service program 124, in 
step 526, via a prooedm-e call. 

It is noted here that the target service program-specific 
buffer could be built immediately without the intermediate 
service request structure. This two-step translation process is 
employed in this embodiment, however, to ease portability 
to different target service programs and different server 
processors. The invention is not limited to a two-step 
translation process. 

Information regarding the pending request is posted to the 
context data store 416 using the context data store manager 
414. One possible format for a pending request entry 518 is 
described in the source code depicted in Table 4. 

TABLE 4 

struct request { 
long flags; 
long msgid; 
union ( 

int handle; 

struct qElement q; 
} msgHandle; 

} 



At this point, the message handler is complete with the 
processing of this inbound message and returns to network 
polling in step 529. 

REPLY MONITOR 

The reply monitor 440 monitors the stams of pending 
target service program requests, generates reply messages to 
the client application, and maintains recovcrability data in 
log entries. To perform its functions the reply monitor 440 
accesses the context data store 416 via the context data store 
manager 414, a log file 442 containing recovcrability data, 
the target service program 124 via procedure calls, and the 
message handlers 430 to send the reply messages it gener- 
ates. 

FIG. 6 shows a flowchart of the main processing loop for 
one embodiment of a reply monitor 440. During operation, 
in step 604, the reply monitor periodically perfonns a scan 
of pending requests posted in the context data store 416. It 
accesses pending request entries 418 using the context data 
store manager 414. In step 606, if there are no pending 
requests, the reply monitor idles for a short period in step 
602 and tries again. If a request is foimd, the reply monitor 
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uses information fi'om the pending request entry 418 to 
format a request to the target service program 124 for status. 
In step 608, if the requested service is completed, reply 
monitor 440 takes the reply from the target service program 

5 124 in step 610. and records it to a log file 442 in step 612 
as a formatted log entry 443. 

It should be noted that the log file 442 could be main- 
tained in non-volatile storage. In such a case, the log file 
information may be used for recovery and is most useful if 

jQ it survives a failure on the server processor. 

A service request structure is built from the target service 
program-formatted buffer in step 614, and a reply service 
message properly formatted for the client application is built 
from the service request structure in step 616. 

In step 618, the reply monitor 440 uses information 
available in the context data store 416 to determine which 
message handler 430 maintains the connection with the 
client application 112 initiating the finished request, and 
forwards the reply service message to that message handler. 
The message handler 430 formats the reply service message 

2^ according to the relevant gateway executor protocol ele- 
ments and forwards it over the network connection 420 for 
transmission to the client processor 110, completing the task 
on behalf of the reply monitor 440. 

Regarding the use of the log file 442 for recovery, it 

25 should be noted that recovery can occur at two levels. There 
can be recovery in the event of an application level failure. 
In other words, the client application fails, the gateway 
executor fails, or both fail before all messages expected ia 
reply to an earlier request are received by the client. One 

30 embodiment able to support recovery at this level includes 
having the gateway executor generating a session identifier 
(SID) unique across its many executions for each such round 
of communication. The SID may then be communicated to 
the client application and stored durably by both the client 

35 application and the gateway executor Both would also 
include functionality for recovery handshaking in such an 
embodiment. 

Recovery can also occur in the event of a network level 
failure. In other words, the client application and the gate- 
way executor continue to function normally, but the con- 

^ nection between them drops out. One embodiment support- 
ing this level of recovery could do so through the use of the 
gateway executor identifier (GEID) and the CID, both of 
which are already included in the gateway executor protocol. 

It should be noted that recovery in the event of network 
failure is first considered in terms of unintended loss of 
connections. This same "recovery** could be deliberately 
employed to create a "connectionless" mode of operation, if 
desired, where the virtual circuit between a CCM and the 
gateway executor is transient, existing only for the discrete 

50 durations of single transmissions or single request-reply 
cycles. 

To summarize, the gateway executor 122 running on the 
server processor 120 has message handlers 430 to perform 
communication with client applications and to initiate 

55 requested services with the target service program 124. The 
gateway executor also has a reply monitor 440 to identify 
requests completed by the target service program 124 and to 
generate reply messages back to the client application. The 
gateway executor 122 thus forms the server processor side 

60 of the bidirectional active channel between a client appli- 
cation and a target service program. The API and CCM 
which form the client processor side of the bidirectional 
active channel will now be described in more detail. 

g5 THE API 

Referring again to FIG. 2, the API 114 connects the client 
application to the CCM 116. On the client application side. 
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the API 114 exposes a number of predefined behaviors to the 
client application 112. Requesting a behavior is how the 
client application communicates to the API. Replying to a 
behavior request is how the API communicates to the client 
application. 5 

Behaviors most often are defined in terms of specific end 
results desired from target service program 124 processing, 
but can also be directed toward gateway executor 122 
processing. Behaviors are often directly related to services 
implemented under the target service program 124. 10 

In a banking application, for example, Withdrawal and 
Deposit are representative services, each which may per- 
form substantial processing. Such processing may include 
account number validation, account status validation, fund 
availability checking, new balance calculation and update, 15 
and a posting operation. 

The Withdrawal and Deposit services implemented under 
the banking target service program are each represented in 
the gateway executor by a repository entry. The API, after 
requesting and receiving the respective repository entries. 20 
and based on information contained therein, presents With- 
drawal and Deposit behaviors to the client application. 
Using the behaviors, the client application needs only to 
include program code to set parameters, request service 
execution, and check results. Table 5 shows an example of 25 
possible source code for a client application using an 
embodiment of a behavioral API to request the target service 
program's Withdrawal service. 

The high-level view of the service request process avail- 
able to the client application is made possible because the 
API 114 and the gateway executor 122, in concert, perform 
the detailed particulars. This involves tedious buffer format- 
ting and management, status checking, and one or more 
procedure calls to the target service program. The API thus 
presents an abstracted view of the service request process 
requirements to the client application. 

It is noted that the abstraction provided by the API 
represents further advantages of the present invention. The 
programming task for the client application is greatly ^ 
simplified— the chent application's behavioral view of ser- 
vices requires a low level of specificity. Portability for the 
client apphcations in an application system is simplified — 
for example, a migration to a different target service pro- 
gram could be accomplished by changing only a portion of 
the gateway executor, and not each and every client appli- 
cation. 

TABLES 

withdrawal - appl.getSynchServiceRequest("Withdrawal") 50 
/• fix withdrawal service definition */ 



withdrawaI.setAa»unt(72359) /' set account number parm */ 

withdrawaUctAmount(300.00) /* set transaction amount parm */ 55 

withdrawal xall /' request service execution •/ 

balance » withdrawal.gctBaiancc /' get rcsulu •/ 



In one embodiment, the API 114 accepts a behavior 
request in a format compatible with the client application 60 
and translates the request into the request service message 
format of the gateway executor protocol illustrated in FIG. 
3(D). 

In one embodiment of the gateway executor protocol, a 
service message 331 contains a service message header area 65 
332 and a service message content area 335. The service 
message header area 332 further contains an SID area 333 
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and operation code area 334. In operation, an SID from the 
gateway executor is placed into the SID area 333. An 
appropriate operation code selected by the API from a set of 
predefined choices is placed into the operation code area. 
FIG. 3(E) depicts one embodiment of a predefined operation 
code scbsme with the operation code values appearing in 
column 341. 

In this embodiment the service message content area 335 
contains parameter information. The structure of the param- 
eter information area for any one instance is determined by 
the operation code 334 in the service message header 332 
and whether the service message origioates from the API (a 
request service message) or the gateway executor (a reply 
service message). FIG. 3(E) depicts one embodiment of 
parameter information structures defined in terms of an 
ordered set of named parameters. Column 344 indicates the 
parameter structure for service messages originating at the 
client for a corresponding operation code in column 341, 
Column 345 indicates the parameter structure for service 
messages originating at the gateway executor for a corre- 
sponding operation code in column 341. 

Prior to formatting the service request into service mes- 
sage fonnat, or as part of the process, the API may perform 
certain validation on the behavior request to detect errors 
locally before transmission to the server processor. 

In one possible embodiment, the API validates against 
information about the service type obtained from the gate- 
way executor repository. The API may use a copy of the 
repository entry previously obtained from the gateway 
executor if one is available, or as part of the process of 
validation may issue a request to the gateway executor to 
obtain repository information including the needed service 
type entry. This "caching" technique, applied here to reposi- 
tory entries, is well knovra in the art and many alternative 
embodiments would be obvious to one skilled in the art. 

When a request service message is properly formatted, the 
API places it in a service message stack. The construction of 
stacks is well known in the art and can take many forms. 
When the stack is complete and ready for transmission to the 
gateway executor, the API hands it off to the CCM, In the 
opposite direction, the CCM forwards to the API service 
message slacks originating from the gateway executor. The 
API fimctions to translate the reply service messages in the 
stack from gateway executor protocol format to client appli- 
cation formal, and passes them on to the client application, 

THE CCM 

FIG. 7 illustrates the structure of one embodiment of the 
CCM 116. The client communications buffer 703 is a data 
area used to hold request and reply service message stacks. 
The client communications buffer 703 has an inter- 
component connection 115 with the API. The TCP/IP Socket 
706 interfaces the client communication handler to the lower 
layers of the network 117 using a single TCP/IP port on the 
chent processor. Tht client communication handler 704 in 
this embodiment creates the socket 705 when the first 
communication with the gateway executor is requested. 

In one embodiment, when request service message stacks 
are received from the API, the client communication handler 
704 attaches a control header to the front of the stack to form 
a gateway executor message 301 as depicted in FIG. 3(A), 
This embodiment of a gateway executor message contains a 
header area 302 and a content area 303. FIG. 3(B) illustrates 
the subcomponents of the header. 

In this embodiment, the header 311 first contains a version 
number area 312, the contents of which represent the version 
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level of the software creating the message. The contents of 
the message code area 313 indicate the source and character 
of the message. FIG. 3(C) describes one embodiment of 
message code definitions and column 321 shows the values 
which may be placed into the message code area 313 during 
operation. 

The message ID area 314 of this embodiment holds a 
reference identifier optionally generated and used by the 
client application for its own purposes — the gateway execu- 
tor ignores the contents of this field other than to copy it to 
the control headers for related reply messages. The cUent ID 
area 315 holds the CID described earlier. The gateway 
executor ID area 316 holds an identifier representing the 
gateway executor for which one implementation involves 
using the operating system's process ID for the gateway 
executor program process. The message length area 318 
holds a number representing the length of the message 
content portion 303 of the related gateway executor message 
301. The reserved area 317 is a placeholder to guarantee the 
beginning of the content length area 318 at a certain offset 
from the beginning of the header 311. 

In an embodiment employing encryption, the entire gate- 
way executor message may be encrypted at this poinl. The 
gateway executor message, ready for transmission, may then 
be sent across the network using the socket. 

The process is reversed for messages received from the 
network in this embodiment. If encryption is implemented, 
decryption takes place. The control header is stripped off and 
the service reply stack is passed to the API. 

In summary, the API and CCM may operate as described 
above to form the client processor side of the bidirectional 
active channel between a client application and a target 
service program. In this embodiment, the API, CCM, gate- 
way executor, and the network together form a complete 
end-to-end channel. 

As apparent from the discussion above, the present inven- 
tion is advantageous because it simplifies chent application 
coding, improves portability, allows legacy TPMs to operate 
over the Internet, enables deployment of Web-based 
applications, and increases recoverabihty and reUability. For 
example, by utilizing the invention to implement a compa- 
ny's employee timekeeping appUcation, a user could support 
direct data entry transactions by employees with Internet 
access, who are dispatched around the globe. In this manner, 
a user could save the substantial expense of a modem bank 
on the server and the associated toU call charges. 

While the invention has been described with reference to 
numerous specific details, one of ordinary skill in the art 
would recognize that the invention can be embodied in other 
specific forms without departing from the spirit of the 
invention. For example, the repository entries of the gateway 
executor could be maintained in an external database by 
using the services of the target service program, rather than 
being maintained in storage. Thus, one of ordinary skill in 
the art would understand that the invention is not to be 
limited by the foregoing illustrative details, but rather is to 
be defined by the appended claims. 

We claim: 

1. An apparatus for connecting a web browser-initiated 
user application program executing on a network-attached 
chent processor to a target service program (TSP) coupled to 
a network-attached server processor, comprising: 

a gateway executor executing on the server processor and 
coupled to the TSP, the gateway executor comprising a 
network connection serving as a first terminus point of 
a network path, a repository for storing information 
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about one or more services requestable from the TSP, 
and a message handler coupled to the network connec- 
tion and the TSP for presenting service requests to the 
TSP; 

5 a client commimication manager (CCM) executing on the 
client processor for establishing and operating a second 
terminus point of the network path; and, 
an application programming interface (API) executing on 
the client processor responsive to the user appUcation 

IQ program and coupled to the CCM, the API communi- 
cating with the gateway executor via the CCM to 
retrieve information from the gateway executor 
repository, and the API responsive to the user applica- 
tion program to communicate with the gateway execu- 
tor via the CCM to request a service from the TSP. 

2. The apparatus of claim 1 wherein the API affects its 
presentation to the user application program in accordance 
with retrieved repository information. 

3. The apparams of claim 1 wherein the logical network 
path between the first terminus point and the second termi- 

20 nus point exclusively conveys communications between the 
terminus points. 

4. The apparatus of claim 1 wherein the gateway executor 
maintains client context data including a context identifier. 

5. The apparatus of claim 4 wherein the context identifier 
25 is exchanged bidirectionally between the gateway executor 

and the CCM. 

6. The apparatus of claim 1 wherein the gateway executor 
generates multiple requests to the TSP in response to a single 
request from the API. 

30 7. The apparatus of claim 1 wherein the gateway executor 
stores a first representation of a service request in response 
to a service request message and a second representation of 
a service request corresponding to the identical service 
request message, the second representation conforming to 

35 the requirements of the TSP. 

8. The apparatus of claim 1 wherein the logical network 
path between the first terminus point and the second termi- 
nus point exclusively conveys communications between the 
terminus points, and wherein the gateway executor main- 

40 tains chent context data including a context identifier, and 
wherein the context identifier is exchanged bidirectionally 
between the gateway executor and the CCM, and wherein 
the gateway executor generates multiple requests to the TSP 
in response to a single request from the API, and wherein the 

45 gateway executor stores a first representation of a service 
request in response to a service request message and a 
second representation of a service request corresponding to 
the identical service request message, the second represen- 
tation conforming to the requirements of the TSP. 

50 9. The apparatus of claim 1 wherein the gateway executor 
maintains client context data including a context identifier, 
and wherein the gateway executor generates multiple 
requests to the TSP in response to a single request from the 
API. 

55 10. The apparatus of claim 9 wherein the context identifier 
is exchanged bidirectionally between the gateway executor 
and the CCM. 

11. The apparatus of claim 1 wherein the gateway execu- 
tor generates multiple requests to the TSP in response to a 

60 single request from the API, and wherein the gateway 
executor stores a first representation of a service request in 
response to a service request message and a second repre- 
sentation of a service request corresponding to the identical 
service request message, the second representation conform- 

65 ing to the requirements of the TSP. 

12. The apparatus of claim 1 wherein the logical network 
path between the first terminus point and the second termi- 
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nus point exclusively conveys communications between the 
terminus points, and wherein the gateway executor main- 
tains client context data including a context identifier. 

13. The apparatus of claim 12 wherein the context iden- 
tifier is exchanged bidirectionally between the gateway 
executor and the CCM. 

14. The apparatus of claim 1 wherein the logical network 
path between the first terminus point and the second termi- 
nus point exclusively conveys coomaunications between the 
terminus points, and wherein the gateway executor gener- 
ates multiple requests to the TSP in response to a single 
request from the API. 

15. The apparatus of claim 1 wherein the logical network 
path between the first terminus point and the second termi- 
nus point exclusively conveys communications between the 
terminus points, and wherein the gateway executor stores a 
first representation of a service request in response to a 
service request message and a second representation of a 
service request corresponding to the identical service request 
message, the second representation conforming to the 
requirements of the TSP. 

16. The apparatus of claim 1 wherein the logical network 
path between the first terminus point and the second termi- 
nus point exclusively conveys conununications between the 
terminus points, and wherein the gateway executor main- 
tains client context data including a context identifier, and 
wherein the gateway executor generates multiple requests to 
the TSP in response to a single request fi-om the API, 

17. The apparatus of claim 16 wherein the context iden- 
tifier is exchanged bidirectionally between the gateway 
executor and the CCM. 

18. The apparatus of claim 1 wherein the logical network 
path between the first terminus point and the second termi- 
nus point exclusively conveys commimications between the 
terminus points, and wherein the gateway executor gener- 
ates multiple requests to the TSP in response to a single 
request from the API, and wherein the gateway executor 
stores a first representation of a service request in response 
to a service request message and a second representation of 
a service request corresponding lo the identical service 
request message, the second representation conforming to 
the requirements of the TSP. 

19. The apparatus of claim 2 wherein the logical network 
path between the first terminus point and the second termi- 
nus point exclusively conveys commimications between the 
terminus points. 

20. The apparatus of claim 2 wherein the gateway execu- 
tor maintains client context data including a context identi- 
fier. 

21. The apparatus of claim 20 wherein the context iden- 
tifier is exchanged bidirectionally between the gateway 
executor and the CCM. 

22. The apparatus of claim 2 wherein the gateway execu- 
tor generates multiple requests to the TSP in response to a 
single request from the API. 

23. The apparatxis of claim 2 wherein the gateway execu- 
tor stores a first representation of a service request in 
response to a service request message and a second repre- 
sentation of a service request corresponding to the identical 
service request message, the second representation conform- 
ing to the requirements of the TSP. 

24. The apparatus of claim 2 wherein the logical network 
path between the first terminus point and the second termi- 
nus point exclusively conveys commimications between the 
terminus points, and wherein the gateway executor main- 
tains client context data including a context identifier, and 
wherein the context identifier is exchanged bidirectionally 
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between the gateway executor and the CCM, and wherein 
the gateway executor generates multiple requests to the TSP 
in response to a single request from the API, and wherein the 
gateway executor stores a first representation of a service 
5 request in response to a service request message and a 
second representation of a service request corresponding to 
the identical service request message, the second represen- 
tation conforming to the requirements of the TSP. 

25. The apparatus of claim 2 wherein the gateway execu- 
tor maintains client context data including a context 
identifier, and wherein the gateway executor generates mul- 
tiple requests to the TSP in re^onse to a single request from 
the API. 

26. The apparatus of claim 25 wherein the context iden- 
tifier is exchanged bidirectionally between the gateway 

15 executor and the CCM. 

27. The apparatus of claim 2 wherein the gateway execu- 
tor generates multiple requests to the TSP in response to a 
single request from the API, and wherein the gateway 
executor stores a first representation of a service request in 

20 response to a service request message and a second repre- 
sentation of a service request corresponding to the identical 
service request message, the second representation conform- 
ing to the requirements of the TSP. 

28. The apparatus of claim 2 wherein the logical network 
25 path between the first terminus point and the second termi- 
nus point exclusively conveys communications between the 
terminus points, and wherein the gateway executor main- 
tains client context data including a context identifier. 

29. The apparatus of claim 28 wherein the context iden- 
30 tifier is exchanged bidirectionally between the gateway 

executor and the CCM. 

30. The apparatus of claim 2 wherein the logical network 
path between the first terminus point and the second termi- 
nus point exclusively conveys communications between the 

35 terminus points, and wherein the gateway executor gener- 
ates multiple requests to the TSP in response to a single 
request from the API. 

31. The apparatus of claim 2 wherein the logical network 
path between the first terminus point and the second termi- 

40 nus point exclusively conveys communications between the 
terminus points, and wherein the gateway executor stores a 
first representation of a service request in response to a 
service request message and a second representation of a 
service request corresponding to the identical service request 

45 message, the second representation conforming to the 
requirements of the TSP. 

32. The apparatus of claim 2 wherein the logical network 
path between the first terminus point and the second termi- 
nus point exclusively conveys communications between the 

50 terminus points, and wherein the gateway executor main- 
tains cUent context data including a context identifier, and 
wherein the gateway executor generates multiple requests to 
the TSP in response to a single request from the API. 

33. The apparatus of claim 32 wherein the context iden- 
55 tifier is exchanged bidirectionally between the gateway 

executor and the CCM. 

34. The apparatus of claim 2 wherein the logical network 
path between the first terminus point and the second termi- 
nus point exclusively conveys communications between the 

60 terminus points, and wherein the gateway executor gener- 
ates multiple requests to the TSP in response to a single 
request from the API, and wherein the gateway executor 
stores a first representation of a service request in response 
to a service request message and a second representation of 

65 a service request corresponding to the identical service 
request message, the second representation conforming to 
the requirements of the TSP. 
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35. A gateway executor apparatus for receiving and 
responding to requests from a Web browser-initiated client 
application program executing on a network-attached client 
machine, the requests for effecting transactional processing 
by a target service program (TSP) comprising: 5 

a network connection; 

a message handler coupled to the network connection and 
the TSP for transforming service requests received over 
the network connection into a format conforming to the 

10 

requirements of the TSP; 
a repository coupled to the message handler for storing 
information about one or more services requestable 
from the TSP 

36. The apparatus of claim 20 further comprising a 
context data store coupled to the message handler for storing 
information about client application program requests. 

37. The apparanis of claim 36 wherein the context data 
store comprises storage for holding a context identifier 
corresponding to a particular client apphcation program 
request. 

38. A method for a client-resident application program- 
ming interface (API) to adapt itself at run time to present to 
a Web browser-initiated client application program an inter- 
face for requesting service over a network connection from 
a target service program (TSP) using the intermediate 
agency of a server-resident gateway executor, comprising: 

requesting information from the gateway executor about 
one or more TSP transactions it can facilitate; 
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receiving TSP transaction information from the gateway 
executor; 

presenting a behavior to a client application program in 
accordance with the received TSP transaction informa- 
tion. 

39. A method for a client-resident applications program- 
ming interface (API) to request service over a network 
connection from a target service program (TSP) on behalf of 
a Web browser-initiated client application program, using 
the intermediate agency of a server-resident gateway 
executor, comprising: 

requesting information from the gateway executor about 
one or more TSP transactions the gateway executor can 
facilitate; 

receiving TSP transaction information from the gateway 
executor; 

presenting a behavior to a client application program in 
accordance with the received TSP transaction informa- 
tion; 

receiving from the client application program a request to 

effect the presented behavior; 
sending a request to the gateway executor for effecting the 

TSP transaction associated with the presented behavior. 

* * * * * 
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